We have several large (?, 60k objects) modules with DXL attributes which do some calculations (gather data from other linked modules). The working speed with the DXL attributes is not quick but acceptable.
Problem arises when opening one of several views which filters on the DXL attributes. Then, we have to stare at the hour glass for at least ten minutes. For testing purposes I have save the same view without the filter - ready in seconds. Why is the filtering so slow? How can it be accelerated?
We are running Doors 8.3 here.
Many thanks in advance,
hgr00
hgr00 - Fri May 28 02:25:53 EDT 2010 |
|
Re: Opening View with Filter on Column Contents is Slow
Mathias Mamsch - Fri May 28 03:31:47 EDT 2010
Hmm.. I suppose you really have DXL attributes and not DXL layout columns (which could explain the filtering time). You should check this first, that there are no DXL layout columns in the view that could cause the problem.
DXL attributes will be calculated, when they are first used, i.e. shown in a view. That means it should make no difference, whether you start up with a filter or not, providing the filter only refers to attributes that are in the view.
One explanation could be, that the filter itself refers to a DXL attribute, that does a lot of work (i.e. opening all kinds of modules in the background, scanning them recursivly). This attribute will only be calculated if you activate the filter.
I am pretty sure the problem is not the filtering. The possibility for speeding up this process depends on the complexity of the DXL attribute. If it really has to open the complete database and read its modules, then you probably cannot do much. But for this you would have to know which script is causing the issue.
Hope this helps, Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Opening View with Filter on Column Contents is Slow
hgr00 - Fri May 28 03:49:58 EDT 2010 Mathias Mamsch - Fri May 28 03:31:47 EDT 2010
Hmm.. I suppose you really have DXL attributes and not DXL layout columns (which could explain the filtering time). You should check this first, that there are no DXL layout columns in the view that could cause the problem.
DXL attributes will be calculated, when they are first used, i.e. shown in a view. That means it should make no difference, whether you start up with a filter or not, providing the filter only refers to attributes that are in the view.
One explanation could be, that the filter itself refers to a DXL attribute, that does a lot of work (i.e. opening all kinds of modules in the background, scanning them recursivly). This attribute will only be calculated if you activate the filter.
I am pretty sure the problem is not the filtering. The possibility for speeding up this process depends on the complexity of the DXL attribute. If it really has to open the complete database and read its modules, then you probably cannot do much. But for this you would have to know which script is causing the issue.
Hope this helps, Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
My current explanation is that the filter requires DXL attribut calculation for all objects. While whithout the filter only the visible objects' attribute are calculated. Most probably, the summed up non-responsiveness of the system is harder to bear than the distributed (one second here, one there). Unfortunately, the DXL code requires background loading of modules of incoming links, iterating over them and so on.
Regards, hgr00
|
|
Re: Opening View with Filter on Column Contents is Slow
Mathias Mamsch - Fri May 28 04:57:00 EDT 2010 hgr00 - Fri May 28 03:49:58 EDT 2010
Thanks, Mathias, for your quick response. We are directly accessing DXL attribute contents for the filter. My first step was to eliminate filtering on DXL layout columns but that did not make much of a difference.
My current explanation is that the filter requires DXL attribut calculation for all objects. While whithout the filter only the visible objects' attribute are calculated. Most probably, the summed up non-responsiveness of the system is harder to bear than the distributed (one second here, one there). Unfortunately, the DXL code requires background loading of modules of incoming links, iterating over them and so on.
Regards, hgr00
Make sure that you have no redundancies in your DXL code, like opening/closing modules more than once or getting the traceability for the same object twice (like you would do, when you evaluate the traceability for two modules that link to the same module). This can be hard to accomplish, when you use DXL Attributes / DXL Layout columns.
A common solution for handling this complexity is to calculate the traceability information on demand and store it to a real attribute, refresh it on demand.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Opening View with Filter on Column Contents is Slow
llandale - Fri May 28 17:06:11 EDT 2010 Mathias Mamsch - Fri May 28 04:57:00 EDT 2010
Just to make this straight: DXL-Attributes are calculated for all object when you access the attribute the first time after loading. DXL Layouts are recalculated on every repainting of the module editor window for the visible objects, unless you filter on the DXL Layout Column, in which case it is executed at least once for every object.
Make sure that you have no redundancies in your DXL code, like opening/closing modules more than once or getting the traceability for the same object twice (like you would do, when you evaluate the traceability for two modules that link to the same module). This can be hard to accomplish, when you use DXL Attributes / DXL Layout columns.
A common solution for handling this complexity is to calculate the traceability information on demand and store it to a real attribute, refresh it on demand.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
>
> Just to make this straight: DXL-Attributes are calculated for all object when you access the attribute the first time after loading.
This is my experience when the result of the DXL is null, but when the result has a value then the its calculated for an object only when that value is referenced the first time after module open. v9.2.0.1 Proved this with this DXL:
obj.attrDXLName = ""
//obj.attrDXLName = identifier(obj)
print "\t" identifier(obj)
Put the code in an attr, display that attr in the view, make the module window thin to show only a few objects, select the top object in the module, save the view remembering current object and windows size. Close and re-open the module and yes, the DXL output has lots of prints. Run 'halt' to erase results. Now swap the first two lines such that the ID is displayed. Save and close, re-open the module and you will see that only displayed objects are printed; scrolling down the module results in more incremental prints.
Back to the original post, I suggest the user really didn't notice the delay in calculation of the attrDXL while scrolling the module since its only a few objects at a time; but when you apply a filter to that attr then ALL object-values are referenced, resulting in delay.
I wonder if the attrDXL opens the linked modules, gets the info, then closes them. Yes that's 'clean' but its VERY slow.
AttrDXL recalculates constantly when the result is empty; thus attrDXL should use a space instead of an empty string, when displaying nothing. The following should be routine at the bottom of attrDXL code:
if (length(bufResults) == 0) //-
then obj.attrDXLName = " "
else obj.attrDXLName = tempStringOf(bufResults)
delete(bufResults)
|
|